home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 6 / CU Amiga Magazine's Super CD-ROM 06 (1996)(EMAP Images)(GB)(Track 1 of 4)[!][issue 1997-01].iso / cucd / online / fidonetts / fsc-0062.003 < prev    next >
Text File  |  1996-06-01  |  16KB  |  343 lines
  1.  | Document: FSC-0062
  2.  | Version:  003
  3.  | Date:     April 14, 1996
  4.  | Author:   David J. Thomas
  5.  
  6.  
  7.  
  8.  
  9.       A Proposed Nodelist flag indicating Online Times of a Node
  10.                                David J. Thomas
  11.                             2:442/600@fidonet.org
  12.  
  13.  
  14.  
  15.  
  16. Status of this document:
  17.  
  18.      This FSC suggests a proposed protocol for the FidoNet(r) community,
  19.      and requests discussion and suggestions for improvements.
  20.      Distribution of this document is unlimited.
  21.  
  22.      Fido and FidoNet are registered marks of Tom Jennings and Fido
  23.      Software.
  24.  
  25.   Note
  26.   ----
  27.  
  28.   Changes in content between the previous edition of this document, and this
  29.   edition, are signified by bars (|) in the left margin, except where
  30.   otherwise specified. I have changed the format of the document slightly to
  31.   allow this. Where the format of the document has changed, but the actual
  32.   text has not, bars are not present.
  33.  
  34.   Purpose
  35.   -------
  36.  
  37.   There are currently several systems within FidoNet that offer file request
  38.   or mail holding capabilities but are not continuously online. The only time
  39.   during which these nodes can be contacted with reference to the nodelist is
  40.   currently the Zone Mail Hour of the zone to which the systems belong. In
  41.   theory, mailers can only use the zone mail hour(s) specified by the system
  42.   in question to contact these nodes, which does not provide for any method
  43.   of file requesting or calling for echomail that does not conflict with the
  44.   Policy requirement that no echomail or files be transferred during the zone
  45.   mail hour. This means that, in practice, if it is known that a particular
  46.   node is online for more time than ZMH alone, but less than 24 hours a day,
  47.   it is necessary to "kludge," or set this up as a special situation, in most
  48.   mailers whenever a node has to be contacted a number of times, whether
  49.   regularly or irregularly. The proposed flag would benefit the mailers in
  50.   such a way as to provide for them the online times that the node is usually
  51.   online for, thus cutting on the costs of calling a non-continuous mail
  52.   node, only to find that it is not available; and also, hopefully preventing
  53.   annoyance for a sysop whose mailer is being called whilst it is not online,
  54.   for example in the case of a voice/data shared line.
  55.  
  56.   Compatibility
  57.   -------------
  58.  
  59.   Since the current nodelist format is always being extended and nodelist
  60.   processors look only for the flags that they know about, there are no
  61.   expected compatibility problems with the suggestion outlined below.
  62.  
  63.   Format of additional nodelist flag
  64.   ----------------------------------
  65.  
  66.   The proposed nodelist flag has the following form:
  67.  
  68.     Txy
  69.  
  70.   where x represents the startup time, and y the end time, in the following
  71.   format:
  72.  
  73.    +------+----+  +------+----+  +------+----+  +------+----+  +------+----+
  74.    |Letter|Time|  |Letter|Time|  |Letter|Time|  |Letter|Time|  |Letter|Time|
  75.    +------+----+  +------+----+  +------+----+  +------+----+  +------+----+
  76.    |   A  |0000|  |   F  |0500|  |   K  |1000|  |   P  |1500|  |   U  |2000|
  77.    |   a  |0030|  |   f  |0530|  |   k  |1030|  |   p  |1530|  |   u  |2030|
  78.    |   B  |0100|  |   G  |0600|  |   L  |1100|  |   Q  |1600|  |   V  |2100|
  79.    |   b  |0130|  |   g  |0630|  |   l  |1130|  |   q  |1630|  |   v  |2130|
  80.    |   C  |0200|  |   H  |0700|  |   M  |1200|  |   R  |1700|  |   W  |2200|
  81.    |   c  |0230|  |   h  |0730|  |   m  |1230|  |   r  |1730|  |   w  |2230|
  82.    |   D  |0300|  |   I  |0800|  |   N  |1300|  |   S  |1800|  |   X  |2300|
  83.    |   d  |0330|  |   i  |0830|  |   n  |1330|  |   s  |1830|  |   x  |2330|
  84.    |   E  |0400|  |   J  |0900|  |   O  |1400|  |   T  |1900|  |      |    |
  85.    |   e  |0430|  |   j  |0930|  |   o  |1430|  |   t  |1930|  |      |    |
  86.    +------+----+  +------+----+  +------+----+  +------+----+  +------+----+
  87.  
  88. | This flag is not intended to be a user flag. The flag is intended to provide
  89. | information to computerised mailer processes, and is not easily read by
  90. | human beings (although they can of course interpret the meaning of the
  91. | flag); most mailers however do not attempt to interpret any information that
  92. | is specified as a user flag, assuming that it is there for the benefit of
  93. | human beings. Such mailers would not be able to make use of the information
  94. | provided, which is the purpose of the flag.
  95.  
  96. | This flag is of course not specified in FTS-0005 at the time of writing, but
  97. | this is not regarded by FidoNet as a problem because other flags in current
  98. | use are not specified in FTS-0005.
  99.  
  100.   The case of the letter could be relevant. Whereas the case is currently not
  101.   used by any flags in the document describing the current format of the
  102.   nodelist, there exists the potential for the case of a letter to have
  103.   relevant meaning. The case has to be correct for the CRC check calculation
  104.   to prove correct, and this would be a good use for the case of the letter.
  105.   If it is necessary to ignore the case, then the upper on-the-hour time
  106.   should be used, i.e. the time that is listed after the upper-case letter.
  107.  
  108. | These times are expressed in UTC so that the flag is useful for systems all
  109.   around the world, without the need for specific time zone information to be
  110.   included in the nodelist. They do not adjust with daylight saving time for a
  111.   similar reason. Note the section on daylight saving time for information
  112.   about handling adjustments without changing the flag; this is important.
  113.  
  114.   Where necessary, the times can wrap around midnight, so for example, for a
  115. | node that is online between the hours of 1800 and 0600 UTC, the flag TSG
  116.   would be a valid indication of this time.
  117.  
  118.   This nodelist entry is not required by any node. It is supplementary to the
  119.   #01, #02, #08, #09, #18, #20 flags and their !xx counterparts, though its
  120.   meaning is different. It has been suggested to me about the possibility of
  121.   an additional flag with the same meaning, but having a W as the first
  122.   letter, indicating that the node is also available for all hours during
  123.   weekends; however, I believe that the simple inclusion of the single flag
  124.   indicated above will solve most problems, as it does indicate a period for
  125.   non-CM nodes during which the node is available, which is all that is
  126.   really required.
  127.  
  128.   Daylight saving time
  129.   --------------------
  130.  
  131.   If a node changes online times with respect to UTC when daylight saving
  132.   time becomes effective (which would be the case with most part time nodes),
  133.   then this is to be taken into account when assigning this flag. An online
  134.   times flag assigned to a node should not be altered for the specific
  135.   purpose of adjusting due to daylight saving time, since large difference
  136.   files (NODEDIFF's) would result if every node was allowed to do this, e.g.
  137.   my node used to be online from 2300 to 0800 in local time, which in winter
  138. | is UTC, but in the summer it becomes BST (British Summer Time). This is one
  139. | hour ahead of UTC, and the corresponding availability times of my node
  140. | during the summer period were 2200 to 0700 UTC. Therefore my online times
  141.   flag would have indicated availability between the hours of 2300 and 0700
  142. | UTC, the daily time period encompassing both times, so the flag would be
  143.   TXH.
  144.  
  145.   Policy considerations
  146.   ---------------------
  147.  
  148.   This is a technical document. However, since the flag could make for an
  149.   increase in the size of difference files, the author feels that the
  150.   following guidelines should be adopted concerning the use of the flag.
  151.  
  152.   The online times flag does not replace the requirement for exclusivity of
  153.   zone mail hour to be maintained. It is still annoying behaviour to have
  154.   this flag and be unavailable during ZMH, just as it is annoying behaviour
  155.   to have the CM (continuous mail) flag in one's entry, and disregard ZMH.
  156.  
  157.   Except for during ZMH, the sysop of a node using this flag finding that
  158.   they need to take their mailer offline during the specified times to
  159.   perform system maintenance, or for any other reason, would not be acting in
  160.   an annoying manner to do so, unless the practice is found to be continuous,
  161.   in which case the flag's times could be reduced, or the flag itself could
  162.   be removed from their node entry.
  163.  
  164.   It should be noted that this flag is present for the benefit of mailers,
  165.   not human beings. This means that the flag should be used only to indicate
  166.   when a mailer is ready to receive calls. A system that uses a FidoNet-
  167.   technology mailer in ZMH, and a human-access only system during other
  168.   period(s) of the day that cannot receive mail, should not use this flag.
  169.   This flag does not explicitly specify online times of a public access BBS,
  170.   although for presumably most nodes with FidoNet-capable software, a public
  171.   access BBS will be available during the times indicated.
  172.  
  173.   Where the flag is used, it should not often be changed. If a situation
  174.   exists, for example, where a node uses a certain set of times during the
  175.   first two weeks of a month, and a different set of times during the
  176.   remainder period, the flag should be set to a time during each day of the
  177.   month when the node is online. For example, if a node is online during
  178.   1800-0800 for the first two weeks, and then during 2200-1000 for the
  179.   remainder, the time flag should specify 2200-0800 only. If there is no such
  180.   time (other than ZMH) then no flag should be used. Of course, any permanent
  181.   changes, and any necessary reductions in the times, should be permitted at
  182.   any time, but changes owing only to daylight saving time should certainly
  183.   be expressly forbidden.
  184.  
  185.   File requests and user access are of course permitted during the online
  186.   times indicated (except ZMH).
  187.  
  188.   The above list may seem rather frightening! Please note that they are
  189.   guidelines rather than rules, unless FidoNet policy has included them as
  190.   rules. In the vast majority of situations where a node is online for a
  191.   fixed set of hours per day, the only thing to watch out for is that you get
  192.   the daylight saving time period right. Then you don't have to worry about
  193.   changing it at any time, except when your own online times change.
  194.  
  195.   Example
  196.   -------
  197.  
  198.   With regard to time zones now; this is a complicated topic, so I wish to
  199.   express an example. Imagine a node in Indiana, USA. It is online for the
  200.   time period beginning 6 o'clock pm (1800) and ending 8 o'clock am (0800).
  201.   This changes with daylight saving time, so the times expressed effectively
  202. | become an hour earlier with respect to UTC during daylight saving time.
  203.  
  204. | Indiana is in the Central time zone, which is 6 hours behind UTC. Therefore,
  205. | the online times in UTC can be expressed as 0000-1400 UTC during winter.
  206. | During daylight saving time, however, the local time for Indiana is 5 hours
  207. | behind UTC. The online times during this period are 0100-1500 UTC. The
  208. | subset should be used, so that the online times flag for the node should
  209. | indicate availability between 0100 and 1400 UTC, which is indicated
  210. | by the flag TBO.
  211.  
  212. | (Thanks to a few people for pointing out that the previous example was in
  213. | error; it assumed that Indiana was ahead of UTC, and not behind as is
  214. | actually the case.)
  215.  
  216.   ANSI C routines to Calculate the Online Times Flag
  217.   --------------------------------------------------
  218.  
  219.   These were not provided in the first edition. Change bars will not be used
  220.   here, since they would interfere with the syntax of the presented routines.
  221.  
  222.   The first program calculates the online times flag from the user's entry of
  223.   the online times of a system, expressed in the local time zone, and the
  224.   offset to UTC used by the user's country. It takes into account that the
  225.   clock is put forward and back once a year by reducing the end time by one
  226.   hour. The program should work on any platform, and has been tested.
  227.  
  228. === start of code ===
  229. /* TIMEFLAG.C
  230.    Calculates FSC-0062 time flag requirement from user input */
  231.  
  232. #include <stdio.h>
  233.  
  234. char *onlineflag(char *on, char *off, int utc_diff);
  235.  
  236. void main()
  237. {
  238.    char on[6], off[6]; int utc_diff;
  239.  
  240.    printf("\nPlease specify the time you come online [HH:MM]: ");
  241.    scanf("%s", on);
  242.    printf("\nPlease specify the time you come offline [HH:MM]: ");
  243.    scanf("%s", off);
  244.    printf("\nSpecify the difference between your local time zone in winter\n"
  245.       "time and UTC (e.g. if your time zone is 6 hours behind UTC,\n"
  246.       "enter 6): ");
  247.    scanf("%d", &utc_diff);
  248.    printf("\nYour online time flag is %s\n\n",
  249.       onlineflag(on, off, utc_diff));
  250. }
  251.  
  252. char *onlineflag(char *ontime, char *offtime, int utcdiff)
  253. {
  254.    int onhour, onmin, offhour, offmin;
  255.    static char flag[4]="T  ";
  256.  
  257.    sscanf(ontime, "%d:%d", &onhour, &onmin);
  258.    sscanf(offtime, "%d:%d", &offhour, &offmin);
  259.  
  260.    if(onmin>30) ++onhour;
  261.    --offhour; /* to correct for daylight saving time */
  262.    onhour = (onhour+24+utcdiff) % 24;
  263.    offhour = (offhour+24+utcdiff) % 24;
  264.  
  265.    flag[1]='A'+onhour;
  266.    flag[2]='A'+offhour;
  267.  
  268.    if(onmin>0 && onmin<31) flag[1] += 'a'-'A';
  269.    if(offmin>29) flag[2] += 'a'-'A';
  270.  
  271.    return flag;
  272. }
  273. === end of code ===
  274.  
  275.   The second program calculates the online times from the time flag, input
  276.   as a pointer to char to the routine (this being of the format "Txy"). It
  277.   returns a pointer to a structure which contains the on- and off-times in
  278.   UTC. This is not a complete program; it is designed to be used by mailers
  279.   to determine the valid online times. It has also been tested.
  280.  
  281. === start of code ===
  282. /* INTFLAG.C
  283.    Interprets online time flags and converts them to a set of UTC times */
  284.  
  285. struct TIMES {
  286.    int on_hour;
  287.    int on_min;
  288.    int off_hour;
  289.    int off_min;
  290. };
  291.  
  292. struct TIMES *interpret_flag(char *time_flag);
  293.  
  294. struct TIMES *interpret_flag(char *timeflag)
  295. {
  296.    static struct TIMES times;
  297.  
  298.    times.on_min=0;
  299.    times.off_min=0;
  300.  
  301.    times.on_hour=timeflag[1]-'A';
  302.    if(times.on_hour>23) {
  303.       times.on_hour -= 'a'-'A';
  304.       times.on_min=30;
  305.    }
  306.    times.off_hour=timeflag[2]-'A';
  307.    if(times.off_hour>23) {
  308.       times.off_hour -= 'a'-'A';
  309.       times.off_min=30;
  310.    }
  311.    return ×
  312. }
  313. === end of code ===
  314.  
  315. | The above routines can be copied and re-used as desired. I am now an
  316. | amazing C programmer, but I still make no guarantees about them! :-)
  317.  
  318.   Summary
  319.   -------
  320.  
  321.   I believe this to be a neat and compact solution to, what is in my opinion,
  322.   one of the gravest problems currently facing FidoNet. In FidoNet, most
  323.   nodes are continuous mail, but it is important for the growth and
  324.   popularity of FidoNet that non-CM nodes do not receive many mailer calls at
  325.   times when they are off line. Users are bad enough in this respect. It is
  326.   also useful for people wishing to contact hubs that are non-CM with mail
  327.   for a downlink, and for people wishing to file request from a node that is
  328.   not CM. There is no need for systems that are only online in zone mail hour
  329.   to adopt this flag; also, there is no need for CM systems to adopt this
  330.   flag.
  331.  
  332.   Contacting the Author
  333.   ---------------------
  334.  
  335.   My board is now online continuously, except for periods of down time during
  336. | which the board is maintained (few and far between now that Linux is used).
  337.   Netmail contact is therefore possible at any time. I went CM because of a
  338.   certain number of nodes calling at the wrong times, and also users. Users
  339.   weren't too bad, but I dislike 0600 am wake-up calls, repeated at regular
  340.   three-minute intervals for an hour, by mailers, rather intensely :-)
  341.  
  342. End of document.
  343.